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(57) Abstract: Ths present 
invention provides ;i method 
and system for the prevention 
of credit card fraud utilizing a 
communication networ!^ A credit 
cardholder, a Unique Identification 
Device (UID), a meichsint, a credit 
card issuer and the generation of 
an approval code constitute the 
main components of the method 
and system. The method and 
system can be applied to both 
traditional credit card transactions 
and "card not present" credit card 
transactions. The invention does 
not require changes to be made 
to cnnent authorization systems. 
It compliments current systems 
by providing a private channel of 
communication between the credit 



caid issuer and the cardholder that is independent of the usual channel used to conduct a transaction. 
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METHOD AND SYSTEM FOR PREVENTING CREDIT CARD FRAUD 

The present invention relates to a method and system for the prevention of 
credit card fraud through the use of a communication network. 



Credit Cards and their use as payment instruments for the purchase of goods 
and services are widely accepted They are used globally throu^ an established 
infrastructure, which eflBciently and conveniently allows payments to be made in 
most areas of the world. A credit card is usually issued to an individual or a company 
by a financial institution or by a credible merchant with established ties to a bank. A 
credit card holder may present it as a payment to a merchant; the card bearer must 
reimburse the credit card company the amoimt of the sale later. 

The most popular method of payment in e-commerce is the credit card. The 
piirchaser browses the virtual stores or merchants and selects the items of interest by 
placing them in a shopping cart. When a decision is made to purchase the items 
select^ the customer is directed to the checkout. During the checkout phase, 
customer is requested to enter credit card data and other personal information. Upon 
completion of fliese steps, the merchant's virtual store processes the data and sends it 
to a credit card processor, and waits for authorization; similar to traditional card 
swipe (PCS) medxods. Once the credit card processor has given the authorization, the 
merchant accepts the order and delivers the ordered item to the purchaser. At this 
stage, the amount of the purchase made awaits to be deducted from the credit card 
holder's account. These types of credit card transactions are very similar in nature to 
mail order/phone order (MOTO) transactions. These transactions along with E- 
commerce transactions are categorized by credit card companies as "card not present" 
transactions. They are regarded as more risky. The rates charged by the merchant 
account providers for credit card transactions in \s4iich the actual credit card is not 
present are generally higjher than card swipe rates charged in physical "card present" 
transactions. This is due to the hig^o: chance of fraud or nonpayment in the "card not 
present" transactions. 

Unfortunately, merchants and the credit card companies alike are sufEering 
from the credit card fraud. Merchants are responsible for chargebacks and credit card 
companies fece the risk of a reduction in the number of merchants who are willing to 
accept this type of transaction. In addition, many consumers are reluctant to shop 
online, fearing fraudulmt use of their credit card. The rate of this sort of crime is 
increasing and is now at an alarming level. It is seen as a major obstacle to the growth 
of e-commerce. 
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. Most of fhe credit card infonnation used for the fiaudulent onlme purchases 
s^parently is obtained in the old-feshioned way: stolen from mailboxes or "swiped** 
through a card reader by accomplices working in restaurants or stores. This stolen 
credit card infonnation is then transmitted to the thief or thieves overseas, who begin 
5 their electronic assault on Internet merchants by charging as much merchandise as 
they can in as short a time as possible. In some cases, they will attempt to ship the 
goods directly to the country they are operating out oi^ where the credit card address- 
verification system can't be used becaxise of stringent privacy laws. In other cases, 
since many Intemet sellers are now wary of shipping e3q)ensive merchandise 

10 overseas, they will enlist accomplices in the Merchant's home country who set up 
"drop sites** in vacant homes or rent living quarters under false names. By the time 
the e-merchant realizes the purchase was made using stolen credit cards, the goods 
and the thieves are gone. These days, a credit card number is a valuable commodity to 
thieves. Thieves do not need the physical credit card to use somebody's credit card 

IS number, particularly in this era of Intemet and catalog shopping; the same applies to 
debit cards. A thief armed with a debit card number can go on a shopping spree, 
financed by the cardholder's checking account. Tech-sawy criminals are devising 
new ways to get their hands on card information. They've figured out that card fraud 
beats holding up someone at gunpoint Ibstead, tfa^re hacking into Intemet databases 

20 filled with customer card data and copying accotmt details encoded on a card's 
magnetic stripe. It appears as if credit card fraud is the bank robbery of the fixture. 

Current solutions vary; Currently, none of the solutions completely eliminate 
fraud. But designing Web sites that require several pieces of infonnation about the 
card and the potential hayei helps a lot. Those items can then be run through 
25 screening software that looks for anomalies and red flags, generating a fi:aud risk 
score. Most of the current approaches focus on huge customer databases that track 
and monitor customer activity to understand behavior patterns of shoppers. Based on 
the collected data and its processing they aim to screen out shopping activity which 
does not match past behavior. 

30 Combating fimid has always been a cost of doing business, long before e- 

commerce came along. But another element unique to Intemet merchants is title cost 
of losing valuable business as a result of fiaud protection efforts. Antifiraud systems 
use algorithms to detect risk, and the systems will reject an order if it &lls within a 
designated realm* 

35 Small merchants can afford to phone each customer vsiiose order is deemed 

too risky. But retailers that deploy such systems on a large scale are forced to let 
orders &11 by the wayside, meaning they could be losing valuable customers. Some 
merchants are declining large percentage of their orders to TniniTniyA firaud, which 
amounts to significant amount of business. 

40 The Credit Card companies have been active in implementing methods to 

prevent credit card fraud. One of these methods is the CW2/CVC2; a three-digit 
security code that is printed on tiie back of cards. Hie number appears in reverse italic 
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at the top of the signature panel at the end (see sanq>le). This program helps validate 
that a genuine card is being used during a transaction. All MasterCard cards, both 
credit and debit, were required to contain CVC2 by January 1, 1997; all Visa cards 
must contain CW2 by January 1, 2001. Card^not-present merchants are being 
5 directed to ask cardholders for CW2/CVC2 when cardholders place orders. 
Merchants ask the cardholder to read this code from the card. The merchant then asks 
for CW2/CVC2 verification during the authorization process. The issuer (or 
processor) validates the CW2/CVC2 and relays the decline/approve results during 
the authorization process. Merchants, by using the CW2/CVC2 results along with 

10 the Address Verification Service (AVS) and authorization responses, can fbsn make 
more informed decisions about whether to accept transactions. In addition, merchants 
using CW2/CVC2 can expect to reduce their chargebacks by as much as 26 percent. 
Previously the three-digit CW2 or CVC2 number followed the 16-digit account 
number printed on the card^s signature panel. The 16-digit account number is now 

15 truncated to four digits on the signature panel. Beginning March 31, 2000, cards 
issued by Equifax will show the last four digits of the account number followed by 
title tifciree-digit CW2 or CVC2 number on the card signature paneL This change 
makes it easier for cardholders to sign their cards. It also makes it easier for 
merchants to compare the signature on the card to the one on the sales draft; no 

20 longer will those 1 9 di^ts (1 6 + 3) get in the way of verifying a signaturel 

The object of the present invention is to provide a method and system for the 
prevention of credit card fimid through the use of a communication network. 

25 Figure l.a. is a general workmg diagram of single code generation 

unpl^nentation in a legitimate transaction. 

Figure l.b. is a general working diagram of single code generation 
implementation in an attempted fraudulent use 

Figure I.e. is system flowchart of single code genemtion implementation. 
30 Figure 2-a. is a general working diagram of shopper check-code generation 

inq>lementation in a le^timate transaction. 

Figure 2.b. is a general working diagram of shopper check-code generation 
implementation in an attempted fraudulent use 

Figure 2.c. is system flowchart of shopper check-code generation 
35 implCTientation. 

Figure 3. a. is a general workmg diagram of merchant check-code generation 
implementation in a legitimate transaction. 

Figure 3.b. is a general working diagram of merdiant check-code generation 
implementation in an attempted fimidulent use 
40 Figure 3.c. is system flowchart of merchant check-code generation 

implementation. 

Figure 4. is a diagram' of information requested by the merchant to process 
and validate titie credit card. 
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Figure 5. is a diagram fhat illustrates the mefhod by ^^ch approval codes 
are generated. 

Figure 6 is a diagram of a look ^xp server. 

5 The present invention provides a method and system for the prevention of 

credit card fiaud utiliTnTig a communication network. A credit cardholder (shopper), a 
Unique Identification Device (UID), a merchant, a credit card issuer and the 
generation of an approval code constitute the main components of the method and 
system, 

10 

The method and system can be applied to both traditional credit card 
transactions ("card present-POS) and "card not present" credit card transactions 
(VPOS- Le. internet purchases, MOTO — i.e.: mail or tel^hone orders). The 
invention does not require changes to be made to current authorization systems. It 
IS compliments current systems by providing a private chaimel of communication 
between the credit card issuer and the cardholder that is independent of the usual 
channel used to conduct a transaction. 

For the purposes of this description we will outline 4 stages in flie 
20 completion of a transaction using a credit or debit card. 

Validation: information necessary for the processing of the credit card is 
checked to be vaUd. i.e. of the correct type and length. Credit card numbers may only 
be valid if they are 16 digits long. 

25 Authorization: when a credit card issuer receives a request to process a credit 

card certain checks are made. The credit card number must match an existing 
account The account must be active and suf&cient funds must be available. This 
process will be referred to as authorization. When a transaction is authorized funds 
are allocated for transfer to &e merchant's account. 

30 Verification: the invention offers the ability to verify the identity of a 

shopper attenipting to use a credit card to make a purchase. The invention can 
determine whether or not the shopper is the cardholder for a specific account This 
process is referred to as verification. 

Approval: vfbien a transaction has been validated, authorized, and verified it 

35 is referred to as an approved transaction. 

The cardholder is an individual or a company, having an active credit card 
accomt with \^ch transactions can be processed. Also used to refer to the actual 
owner of an identification device siq}pUed by any organization used for verifying the 
40 relationship between the organization and the individual 

The shopper is any individual, company, govenmient organization or private 
organization that initiates an action i^ch requires approval of a purchasing process 
using credit card. The shopper may or may not be the actual cardholder 
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himsel£lierselfl If the shopper is not the cardholder, he/she is atten^ting to use the 
credit card fiaiidulently. 

The credit card issuer is a public or private organization that issues credit 
5 cards or debit cards to be used for the purchase of merchandise or services. Credit 
card issuer then bills the customer and is responsible for maintaining the cardholder's 
personal and card related data. Hie term may also be used to refer to an agency acting 
on behalf of Hie issuing body. 

10 Unique Identification Device (UID) refers to a device, specific to the 

cardholder, that provides communication or sharing of ioformation between parties. 
Such a device has a privacy property that is known to the device owner. Examples of 
UID's include GSM phones, e-mail accounts, pagers, personal conq>uters, Intemet 
enabled PDA's (Personal Digital Assistants) and similar devices. UID's may have the 

15 capacity to store and execute programs. A UID may be capable of only unidirectional 
communication. A pager is an example of such a UID. It can receive a message but 
cannot respond to it Other UID's allow for interactive bi-directional communication. 
A telephone (wireline) or mobile phone (wireless) may receive and send voice and 
text messages such as those used in SMS (Short Message Service). An email account 

20 may send and receive messages. 

An approval code is generated and exchanged between Ihe credit card issuer, 
ibe shopper (cardholder), and/or the merchant for identification, verification and 
purchase approval. An approval code is a series of alphanumeric characters and is 
25 only accessible by the credit card issu^, the cardholder and cardholder-authorized 
third parties via the cardholder's UID. By exchanging the approval code among the 
involved parties, the inv^ition verifies the identily of the cardholder and prev^its 
unauthorized use. 

30 Hie method and system and its implementation variations are explained as 

follows; 

Single code generation implementation. 

An ^proval code is generated by the credit card issuer and is either sent 

35 directly to tiie cardholder's UID or made available to the cardholder throu^ a secure 
channel of distribution such as a web site. The cardholder enters the code when the 
merchant's system prompts for it. When the code has been entered in the merchant's 
system, it is sent to the credit card issuer for comparison. The credit card issuer 
carries out comparison of the approval codes. Code generation does not take place on 

40 file merchant's system. Ibis alternative is shown in detail in Figs l.a I.e. 

Shopper check-code generation implementation. 

Code generation takes place both on the credit card issue's system and on 
the cardholder's UID, \)^ch, in this alternative, must be capable of storing and 
45 executing a program. The code generated by the UID is requested by fiie merchant 
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system as part of the infoimation necessaiy to initiate a transactioiL Tliis approval 
code is Hien sent to the credit card issuer for comparison of tiie codes. Hiis alternative 
is shown in detail in Figs 2.a-2.c. 

5 

Merchant check-code generation implementation. 

Code generation takes place on both the credit card issuer's system and the 
merchant's system. The approval code generated by the credit card issuer is sent to 
10 the cardholder's UCD. The merchant's system is responsible for comparison of the 
codes. This alternative is shown in detail in Figs 3.a-3.c. 

Single code generation implementation in detafl. 
Accompanying figures 
IS 1 .a Flow of information in a legitimate transaction 

1 .b Flow of infomiation in an attempted fraudulent use 
1 .c System Flowchart 

In this scenario, the credit card issuer does not VKify tiie identity of the 
20 shopper unless the merchant site sends an approval code. An approval code is 
generated by the credit card issuer's system. This code may either be sent directiy to 
the credit cardholder's UID or made available on demand to the credit card holder. 
The cardholder then provides the merchant with the approval code. In the case where 
the shopper is the actual cardholder they will be able to provide the correct code but if 
25 the shopper is not the cardhold^ then they will not be able to provide the approval 
code. 

The merchant system sends the approval code received ftom the shopper to 
the credit card issuer. The credit card issuer receives and conq)ares the two approval 
codes (Credit card issuer generated approval code and merchant sent approval code). 
30 If the codes match each other then the credit card issuer verifies the identity of the 
shopper, approves the order and notifies the merchant. 

The scenarios below describe the processes involved in a legitimate transaction and in 
a case of attempted fiaudulenl use. The exanq)les use e-commerce as a context but the 
35 same processes would s^ply in any transaction. 

The actaal cardholder initiates the credit card transaction and the 
credit card issuer is metiiod-enabled. The merchant's web site has been modified 
to handle the method and system (Fig. l.a): 

40 

Step 1- During a typical on-line purchase; the credit card holder (shopper) 
completes the selection of products or services over the e-commerce site. The shopper 
then enters his/her credit card data along with other personal information such as 
address, etc. to merchant's site. 
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Step 2 - The shopper's credit card data is sent for aufhotization by the credit 
card issuer. 

Step 3 - The credit card issuer checks the incommg data sent by the 
merchant Hie credit card is then audioiized. The transaction itself is not yet 
5 cojxipleted. An stpproval code is generated by the credit card issuer's system. This 
coiie is either sent to the UID of the cardholder or made available to them on demand. 
The credit card issuer may have obtained the cardholder's UID access data 
previously. 

Step 4 - The merchant asks for an approval code field to be filled in by the 
1 0 shopper. To complete the transaction the shopper enters the approval code. 

Step 5 - The merdiant site sends the approval code supplied by tiie shoppy to 
the credit card issuer for comparison. 

Step 6" The credit card issuer checks the incoming code and verifies the 
identity of the shopi>er. The credit card issuer then sends the approval confirmation to 
IS 1h(} merchant. 

The credit card transaction is initiated by an unauthorized shopper 
(firaudulent card use) and the credit card issuer is method enabled. The 
merchant's web site has been modified to handle the method and system (Fig. 
20 1.1>): 

Step 1 - During a typical on-line purchase the shoppy completes the 
selection of products or services over the e-commerce site. The shopper then enters 
his/her credit card data along with other personal information such as address, etc. to 
25 the merchant's site. 

Step 2 - The shopper's credit card data is s&A for autiiorization by the credit 
card issuer. 

Step 3 - The credit card issuer checks the incoming data sesat by the 
merchant. The credit card is then authorized for use. The transaction itself is not yet 

30 completed. An approval code is generated by the credit card issuer's system. This 
ccide is either sent to the UID of the cardholder or made available to them on demand, 
nie credit card issuer may have obtained the cardholder's UID access data 
pieviously. If the spproval code has been swt to the cardholder's UID then the 
C£rdhold^ is aware tiiat a third party is attemptmg to carry out a transaction usmg 

35 tiaeir credit card and can respond by contacting tiie credit card issuer. This contact 
may be fiicilitated by a ^reply' fiinctionality included in the approval code messages 
that are sent to the cardholder's UID. When tiie cardholder receives tiie approval code 
message they can reply to it, usually using a built in function of their UID. The 
oiiginator of the message would then receive the reply and could act on it by 

40 triggering an alarm message or procedure. Ihe ultimate aim of tiie 'reply' 
fimctionality is to a\xtomate the process of informing a credit card issuer that 
attempted firaudulent use of a card is taking place. 

Step 4 - The merchant asks for an ^>proval code field to be filled in by the 
shopper. The shopper, who is not the cardholder, has not received the approval code 

45 and cannot supply it 
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Step 5 - Hie meichant site sends eithei no approval code or an mcorrect code 
supplied by the shopper to the credit card issuer for comparison. 

Step 6 - The credit card issuer checks the incoming code and cannot verify 
the identity of the shopper. Credit card issuer then informs the merchant that approval 
5 for the transaction caimot be given. 

Flowdbaxty refer to Fig. l.c; 

Merchant: 

10 

In step 4100 and 4101, the information entered by the shopper is validated. 
In step 4102, the validated customer data by the merchant site is sent to the credit 
card processor for data processing and routing for credit card authorization. The 
information is sent to credit card issuer by the credit card processor or similar 
1 S organizations in the; following step 4300. 

In step 4103, the result of the authorization request is received fix>m the credit card 
issuer. 

In step 4104, the authorization message &om the credit card issuer is evaluated. If 
authorization is obtained then step 4106 is processed, otherwise step 4110 is 
20 processed. 

In step 4106, tlie merchant site receives the approval code entered by the shopper. 
In step 4109^ the sliopper data along with the approval code entered by the shopper is 
communicated to the credit card issuer for ^proval. At this moment, the order has 
not been approved by the credit card issuer. 
25 In step 41 10, the merchant system informs the shopper that the transaction has either 
not been authorized or not been approved. 

In step 4111, the merchant site gets the final purchase approval firom the credit card 
issuer. 

In step 4112, the cjredit card issuer's response is evaluated. If the credit card issuer 
30 has approved the order then step 4113 is performed. Otherwise, the step 4110 is 
processed. 

In step 4113, the ciredit card issuer has approved the order.- Hie merchant informs the 
shopper about the purchase order approval. 

35 The Shopper: 

Jn step 4200, the shopper enters all the information requested by the merchant's site. 
Figure 4 shows the information requested by the merchant to process and validate tiie 
credit card- 

40 In the steps 4201 and 4202 the shopper/cardholder receives tbie approval code and 
enters it into the merchant site. 

Only the cardholder can obtain the approval code. Shoppers vAxo are not cardholders 
will not receive the correct approval code. 

45 Credit Card Processor: 
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In steps 4300 and 4303, the credit card processor receives the data in a predetermined 
format, processes it and then routes it to the destination for furdier processing and 
authorization. At this stage, the merchant supplied data is handled by the credit card 
5 processor and communicated to the credit card issuer. The credit card processor and 
other intermediary organizations use different versions of VPOS software and 
systems to process credit card authisrizadon requests. The procedures are similar but 
may display some variations depending on the credit card association and the 
different countries involved. 

10 

The Credit Card Issuer: 

In step 4401, the credit card issuer receives the credit card authorization request and 
processes it using flie credit card customer data it possesses according to the 
IS procedures and rules established by the credit card associations and the countries 
involved in the particular transaction. 

In step 4402, the credit card issuer receives the data fiom the merchant for first 
aufliorization. If the credit card is n ot authorized then this information is passed to the 
merchant (step 4301). If the credit card is authorized thrai step 4403 is processed. 

20 In step 4403, authorization information is sent to the merchant by step 4301 . 

In step 4404, the oredit card issuer generates an approval code that is sent to the 
cardholder's UID. The UID access information is in the credit card issue's database 
and it has been obtained by the bank during initial card issuing process. 
In step 4405, The shopper data along with the approval code entered by flie shopper is 

25 communicated to the credit card issuer for final approval. 

In step 4406, the approval code received from the merchant entered by the shopper 
and the one generated by the credit card issuer are compared. If the approval codes 
match then the identity of the shopper is verified and step 4407 is performed. If they 
do not match then step 4408 is processed. 

30 In step 4407, the transaction is approved. Merchant is notified via step 4303 . 

In step 4408, the credit card issuer does not ^iprove the transaction and sends this 
information to the merchant via step 4303. 

35 POS processing for sln^e code generation implementation* 

The invention applies to traditional credit card purchases as well as on-line, 
mail order or telephone "card not present" transactions. During a traditional credit 
card purchase, merchants use a physical POS device to swipe tiie credit card. Most 

40 currmt POS devices are equipped witii a keypad. In order to apply the uxvention to 
regular POS processmg, all the merchant system is required to have is a shopper 
inter&ce that accepts approval codss (sent by the credit card issuer to shopper^s UID) 
and conmumicates them to the credit card issuer. This interface may use the regular 
POS device or merchant supplied secure data CTtry device. If the correct approval 

45 code cannot be sent to the credit card issuer in a predefined period of time then the 
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credit card issuer cancels the approval process and fhe entire process needs to be 
started from the beginning. The merchant swipes the card through the POS device. 
The CTedit card issuer auOxorizes the transaction but does not approve the order at this 
time. An approval code is generated by the credit caixl issuer and sent to the UID of 
5 the cardholder. The cardholder is standmg by the POS device and expecting to 
receive an approval code via his/her UID. The mesisage comes to the UBD of the 
cardholder. The cardholder enters the approval code by using merchant provided 
interface (i.e., POS device's own buttons). The approval code is sent to the credit card 
issuer. Hie credit card issuer compares the codes to verify the identity of fhe shopper 
10 and either approves the order or not. This logic makes the system extremely secure 
since each code generated is unique and for one-time use only. 

Shopper check-code generation implementation. 

Accompanying Jigures 
15 2.a Flow of information in a legitimate transaction 

2.b Flow of infonnation in an attempted fraudulent use 
2.C System flowchart 

In this second scenario, the cardholder's UID is a programmable device and is 
20 capable of generating an approval code. Both flie credit card issuer and the 
cardholder's UID generate approval codes. Jn order for these codes to match both 
code generation processes need access to the code generation key. Figure 5 illustrates 
the method by \rfiich approval codes are generated with or without the use of code 
generation keys. The code generation key is an alphsinumeric code used to verify tide 
25 identity of an individual attempting to use a credit curd, debit card, or other account 
The code generation key is assigned by the credit card issuer or diosen by the 
cardholder and accessible only by the credit card issuer and the cardholder. 

Another fector used in the generation of an approval code is a time/date 
30 value. The use of a time/date value ensures that the value generated as an approval 
code will be time sensitive. Approval codes will, therefore, have a limited lifespan. 
Tbe length of this lifespan can be varied to meet the demands of the specific 
implementation. In one inq>lementation, for example, the li&span of tiie approval 
code could be set to 15 minutes, ejosuring that a code genemted at 9:00am would 
35 cease to be valid at 9:16am. 

In order to avoid localization issues and ensure ttiat approval codes generated in 
different locations match, all systems involved in a transaction should base their 
generation of approval codes on an agreed .time-zcoie and make an adjustment for 
40 their local time zone before carrying out a comparison of approval code values. In a 
transaction for a shopper in Istanbul (GMT +2), purchasing goods or services from a 
merchant in London, using a card issued by a credit card issuer in New Yoik (GMT - 
5), three different time zones may be involved. Any time-based iaput into approval 
code generation would need to be based on a singile time zone. If GMT is the agreed 
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standard then systems in Istanbul would use local time -2 and systems in fhe USA 
would use local time + 5. 

The scenarios below describe the processes involved in a legitimate 
S transaction and in a case of attenq>ted fraudulent use. The examples use e-commerce 
as a context but the same processes would apply in any transaction. 

The actual cardholder initiates the credit card transa<ction and the 
credit card issuer is method-enabled. The merchant's web site has been modified 
to handle the method and system (Fig. 2.a): 

10 

Step! - During a typical on-line purchase the credit cardholder (shopper) 
completes the selection of products or services over the e-commerce site. The shopper 
then enters his/her credit card data along with other personal infonnation such as 
address, etc. to the merchant's site. In this step, an ^proval code is specifically 
IS requested by the merchant system. The shopper enters the approval code generated by 
his/her UID. 

Step 2 - The merchant sends the data required for approval (including the 
approval code entered by the shopper) to the credit card issuer. 

Step 3 - the credit card issuer generates an approval code. This approval code 
20 is compared with the approval code sent by the merchant If the credit card 
information is correct and the approval codes match then the transaction is ^proved 
by the credit card issuer and the merchant is notified of the approval. 

The credit card transaction is initiated by an miauthorized shopper 
25 (fraudulent card use) and the credit card issuer is method enabled. The 
merchant's web site has been modified to handle the method and system (Fig. 
2.b) : 

Step 1 - During a typical on-Une purchase the shopper completes the selection 
30 of products or services over the e-commerce site. The shopper then enters his/her 
credit card data along with other personal information such as addiiess, etc. to the 
merchant's site. In this st^ an approval code is specifically reijpiested by the 
merchant's system. As the shopper is not the actual cardholder, the^ approval code 
generated by the cardhold^'s UID caxmot be accessed by the shoppt^r. The shoppy 
35 either does not enter an approval code or enters an incorrect approval code. 
Step 2 - The merchant sends the data to the credit card issuer. 
Step 3 - t he credit card issuer generates an approval code. This approval code 
is compared with the approval code sent by the merchant The approval codes will not 
match, since the actual ^>proval code cannot be accessed by the shopper. The credit 
40 card issuer does not approve the transaction request Credit card issuer then sends the 
result of the approval request as not ^proved to the merchant 

Flowchart, refer to Fig. 2.c; 

45 Merchant: 
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In step 5100 and 5101, the information entered by the shopper is validated. 
In step 5102, the validated customer data is sent by the merchant site to the credit 
card processor for data processing and routing for credit card authorization. Hie 
5 information is sent to the credit card issuer by the credit card processor or similar 
organizations in the following step 5300. This mformation also contains the approval 
code entered by the shopper. 

In step 5110, the merchant system warns the shopper that the transaction is not 
approved and stops the processing of the purchase request 
10 In step 5111, the merchant site gets the final purchase approval ftom the credit card 
issuer. 

In step 5112, the credit card issuer's response is evaluated. If the credit card issuer 
has approved the order then the step 5513 is performed. Otherwise, the step 5110 is 
processed. 

15 In step 5513, the credit card issuer has approved the ord^. The merchant informs the 
shopper abouct the purchase order approval 

The Shopper: 

20 In step 5200, the shopper enters all the information requested by "die merchant's site. 
Figure 4 shows the information requested by the merchant to process and validate the 
credit card. In this step, an approval code is specifically requested by the merchant 
system. 

In step 5203, the shopper is informed 'diat the transaction has not been approved. 
25 In step 5204, the shopper is informed ihsA the transaction has been approved. 

Credit Card Processor: 

In steps 5300 and 5303, the credit card processor receives the data in a predetermined 
format, processes it and then routes it to the destination for further processing and 
authorization. At this stage, the merchant siipplied data is handled by the a:«drt card 
processor and communicated to the credit card issuer. The credit card processor and 
other intermediary organizations use different versions of VPOS software and 
systems to process credit card authorization requests. The procedures are similar but 
may display some variation depending on the credit card association and the different 
countries involved. 



The Credit Card Issuer: 
40 In step 5401, the credit card issuer receives the credit card fig>proval request and 
processes it using the credit card customs data it possesses according to the 
procedures and rules established by the credit card associations and the countries 
involved in the particidar transaction. 

In step 5404, the credit card issuer generates an apiiroval code. 
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In step 5406, the ^roval code received fix)m the merchant and the one generated by 
the credit card issuer are compared. If the q>proval codes match, step 5407 is 
performed. If not, then step 5408 is processed. 

In step 5407, tiie transaction is approved. Merchant is notified via step 5303. 
5 In step 5408, the credit card issuer does not approve the transaction and sends this 
information to the merchant via step 5303. 

POS processing for shopper check-code generation. 

10 The invention applies to traditional credit card purchases as well as on-line, 

mail order or telephone "card not presenf * transactions. During a traditional credit 
card purchase, merchants use a physical POS device to swipe the raredit card. Most 
recCTt POS devices are equipped with a keypad In order to apply the invention to 
regular POS processing, all the merchant system is required to have is a shopper 

15 interface that accepts approval codes (generated hy the shopper's UID) and 
communicates them to the credit card issuer. This inter&ce may use the regular POS 
device or merchant supplied secure data entry device. If the correct approval code 
cannot be sent to the credit card issuer in a predefined period of time then the credit 
card issuer cancels the approval process and the entire process needs to be started 

20 fi:om the beginning. The merchant swipes the card through the POS device. The credit 
card issuer authorizes the transaction but does not approve the order at this time. An 
approval code is generated by the cardholder's UID. The cardholder enters the . 
approval code by using merchant provided inter&ce (Le., POS device's own buttons). 
The approval code is sent to the credit card issuer. The credit card issuer compares 

25 the codes to verify the identity of the shopper and either approves the order or not 
This logic makes the system extremely secure since each code generated is unique 
and for one-time use only. 

Merchant checkrcode generation implementation. 

30 Accompcmying figures 

3.a Flow of information in a legitimate transaction 
3.b Flow of information in an attempted firaudulent use 
3.C Sjrstem flowchart 

35 In this third scenario, the approval code generation may take place on both 

the merchant and the credit card issuer's system. The comparison of codes must tate 
place on the merchant's system. 

When a shopper wishes to make a purchase using a credit card they STq)ply 
40 their credit card data to the merchant system. This information may or may not 
include a code generation key. The merchant system will sent the credit card related 
information to the credit card issuer for authorization. If a code generation key is 
supplied it will be used to generate an approval code. 
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Hie CTedit caid issuer receives 'Qie infonnatioii siq>plied by the merchant and 
either authorizes or declines the transaction request If the request is authorized and 
the card is protected by the invention then the credit card issuer generates an approval 
code and sends it to the UK) of the cardholder. 

5 

If the credit card issuer authorizes the transaction and the shopper has 
provided a code generation key thm the shopper wUl be prompted by the merchant to 
enter the approval code sent to their UID by the credit card issuer. The merchant can 
then make the comparison between the code it has generated and the code entered by 
1 0 the shopper. The transaction is eifter verified and approved or declined. 



The table below shows the possible combinations of processes that characterize a 
credit card transaction based on merchant and credit card issuer's status. 



No 


Invention 
Enabled 


Not Invention 
Enabled 


RESULT 


1 


Merchant 

Credit Card 
Issuer 




The identity of the shopper is verified as 
the authorized user of the credit card. If 
the shopper is attempting to use the card 
firaudulendy and does not enter a code 
generation key then the cardholder is 
made aware of this firaudulent use by the 
approval code beiag sent to their UID. 
If the shopper enters an incorrect code 
generation key then the transaction is 
not approved. 


2 


Credit Card 
Issuer 


Merchant 


The invention will inform the 
cardholder if atten:q>ted fraudulent credit 
card use is in progress. Although the 
credit card issuer n:iay authorize the 
transaction the cardholder can inform 
the Issuer as soon as the approval code 
is received by their UID, 


3 




Merchant 

Credit Card 
Issuer 


Transaction proceeds using current 
authorization process. 


4 


Merchant 


Credit Card 
Issuer 


Shopper will not provide a code 
generation key. Transaction proceeds 
using current authorization process. 
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The scenarios below describe the processes involved in legitiniate 
transactions and in cases of attempted fraudulent use. The examples use e-comm^e 
as a context but the same processes would apply in any transaction. 

5 The credit card transaction is initiated by the actual cardholder and the 

credit card issuer is method-enabled (Fig.3.a): 

Stepl - IDuring a typical on-line purchase the credit cardholder (shopper) 
completes the selection of products or services over the e-commerce site. The shopper 
10 then enters his/her credit card data along with other personal information such as 
address, etc. to the merchant's site. The merchant specifically requests a code 
generation key from the shopper. The shopper is the cardholder and has access to this 
key. 

Step 2 - The merchant sends the data required for authorization to the credit 
15 card issuer. 

Steps - The credit card issuer authorizes the transaction, allocates funds for 
transfer to the merchant's account and generates an approval code which is seat to the 
cardholder's UID. 

Step 4 - Because the shopper has provided a code generation key the 
20 merchant prompts the shopper for an approval code. The shopper enters the ^proval 
code sent by the credit card issuer to his/her UID. The merchant compares the 
£^proval codes, verifies the identity of the shopper and approves the transaction. 

The actual cardholder initiates the credit card transaction and the 
25 credit card issuer is not method-enabled (Big. 3.a): 

Step 1 - During a typical on-line purchase the credit cardholder (shopper) 
completes the selection of products or services over the e-commerce site. The shopper 
then enters his/her credit card data along with other personal information such as 
30 address, etc. to die merchant's site. The merchant specifically requests a code 
generation key from the shopper. Ihe shopper does not have access to a code 
generation key because their credit card issuer has not provided them witii one. The 
shopper leaves this field blank. 

Step 2 - The merohant sends the data required for aufhorizadon to the credit 
35 card issuer. 

Step 3 - I he credit card issuer authorizes the transaction and allocates funds 
for transfer to the merohant's account. No approval code is generated as the credh 
card issuer is not using the inventioiL 

Step 4 - T he merohant does not prompt the shopper for an £5}proval code as 
40 no code generation key has been provided. The transaction is complete. This 
transaction is uneffected by the invention. 

The credit card transaction is initiated by an unauthorized shopper 
(fraudulent card use) and the credit card issuer is method-enabled ^g. 3.b): 
45 (Fig. 3.b) 
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Step 1 - During a typical on-line purchase liie shopper (unaufhorized) 
completes the selection of products or services over the e-commerce site. The shopper 
then enters the cardholder's credit card data along with other personal information 
such as address, etc. to the merchant's site. The merchant specifically requests a code 
5 generation key from the shopper. The shopper does not have access to the 
cardholder's code generation key. The shopper may enter an incorrect key or leave 
the field blank. 

Step 2 " The merchant sends the data required for authorization to the credit 
card issuer. 

10 Step 3. The credit card issuer authorizes the transaction, allocates funds for 

transfer to the merchant's accoimt and generates an approval code, which is sent to 
the cardholder's UID. 

Step 4. If the shopper has provided a code generation key then the merchant 
site will prompt them for an approval code. This code is only available through the 

IS cardholder's UID and the shopper will not be able to obtain the code. In this case the 
merchant will not complete &e transaction. If the shopper has not provided a code 
generation key then the merchant site will not prompt for an approval code and will 
complete die transaction. In either case the cardholder is made aware that a third party 
is attraipting to carry out a transaction using their credit card and can respond by 

20 contacting die credit card issuer. This contact may be facilitated by a *reply' 
functionality included in the approval code messages that are sent to the cardholder's 
UID. When the cardholder receives the approval code message they can reply to it, 
usually using a built in function of their UID. The originator of the message would 
then receive the reply and could act on it by triggering an alarm message or 

25 procedure. The ultimate aim of the 'reply' functionality is to automate the process of 
informing a credit card issuer that atteir^ted fraudulent use of a card is taking place. 

The credit card transaction is initiated by an unauthorized shopper 
(fraudulent card use) and the credit card issuer is not metibiod-enabled ^g. 3.b): 

30 

Step 1 - During a typical on-line purchase the shopper (unauthorized) 
completes the selection of products or services over the e-commerce site. The shopper 
thm enters the cardholder's credit card data along with other personal information 
such as address^ etc. to merchant's site. The merchant specifically requests a code 
35 generation key from the shopper. The shopper does not have access to the cardholders 
code generation key. Hie shopper may enter an incorrect key or leave the field blank. 

Step 2. The merchant sends the data required for authorization to the credit 
card issuer. 

Step 3- Tbe credit card issuer audiorizes the transaction and allocates funds 
40 for transfer to die merchant's account. 

Step 4. The merchant site receives the authorization from the CTedit card 
issuer. Ibe transaction is concplete. This transaction is uneffected by the invention. 

Flowchart, refer to Fig. 3.c; 

45 



16 



wo 02/059849 



PCT/TROl/00003 



The Merchant; 

Li step 3100 and 3101, the infotmation entered by the shopper is validated. 
In step 3102, the validated customer data is sent by the merchant site to the credit 
5 card processor for data processing and routmg for credit card authorization. The 
informatioii is sent to the credit card issuer by the credit card processor or similar 
organizations in step 3300. 

In step 3103, the authorization result is received fiom the credit card issuer 
In step 3 104, the authorization result fix>m the credit card issuer is evaluated 

10 hi step 3105, if the transaction is not authorized then the merchant site informs the 
shopper about this &ilure. If the transaction is authorized then step 3107 is processed. 
In step 3107, an evaluation is performed to determine whether the shopper has 
provided a code generation key. If no code generation key has been provided then 
step 3112 is performed. Step 3112 represents ttie normal conclusion of a credit card 

IS transaction without the protection of the invention. If the shopper has provided a code 
generation key then step 3 1 08 is processed 

In step 3108, an approval code is generated using the code generation key provided 
by the shopper. 

In step 3 109, the merchant site receives the approval code entered by the shopper. 

20 In step 3110, the code generated by the merchant site and the code entered by the 
shopper are checked to determine if they match. If the codes are the same then the 
order is accqpted and tihe step 3113 will be processed. If the approval codes do not 
match dien the merchant is aware that the identity of the shopper has not been 
verified. The merchant may eitiier accept the order and ship flie products, accepting 

25 the risk that die credit card issuer may revoke the transaction at a later date (NO 1), or 
refuse to accept the order and cancel the transaction by communicating wilh the oredit 
card issuer (NO 2). 

The Shopper: 

30 

Jn step 3200, the shopper enters all the information requested by the merchant's site. 
Figure 4 shows the information requested by the merchant to process and validate the 
credit card. The shopper is also asked to provide a code generation key. 
In steps 3201, fb& shopper receives tihe approval code sent to &e cardholders UID by 

35 the credit card issuer. 

In step 3202, the approval code is provided to the merchant site by the shopper. 
The shopper can obtain the approval code only if the shopper is flie cardholder. If the 
cardholder receives an ^jproval code for a transaction they have not initiated they are 
made aware that a third party is attempting to carry out a transaction using their credit 

40 card and can respond by contacting tihe credit card issuer. This contact may be 
fecilitated by a 'reply' functionality included in the approval code messages that are 
sent to the cardholder's UID. When the cardholder receives the approved code 
message they can leply to it, usually using a built in function of their UID. The 
originator of the message would then receive the reply and could act on it by 

45 triggering an alarm message or procedure. The ultimate aim of the 'r^ly' 
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fimctioBality is to automate the process of infoimmg a credit card issuer that 
attempted fiaudulent use of a card is taking place. 

Credit Card Processor: 

5 

In steps 3300 and 3301, the credit card processor receives the data in a predetermined 
format, processes it and then routes it to the destination for fiirther processing and 
authorization. At this stage, the merchant supplied data is handled by the credit card 
processor and communicated to the credit card issuer. The credit card processor and 
10 other intermediary or^nizations use differ^ versions of VPOS software and 
systems to process credit card authorization requests. The procedures are similar but 
may display some variations depending on the credit card association and the 
dif^rent countries involved. 

1 5 The Credit Card Issuer: 

la step 3400 and step 3401, the credit card issuer receives the credit card 
authorization request and processes it using the credit card customer data according to 
the procedures and rules established by the credit card associations and the countries 

20 involved in the particular transaction. 

In step 3401, if the credit card is not authorized then tins information is passed to the 
merchant via steps 3301. If the credit card issuer authorizes the credit card fliis 
information is also passed to the merchant following the same steps. 
In step 3402, if the credit card issuer is protected by the invention then step 3403 is 

25 processed and an approval code is sent to the cardholders UID in Step 3301 . 

In step 3403, the credit card issuer generates an approval code. This approval code is 
sent to the cardholder's UID. But in this step the credit card issuer is not sure whether 
the approved purchase is fraudulent or not even if the card has authorized. 

30 LOOK UP SERVER OFHON 

In the above scenarios the merchant cannot identify whether or not an 
individual credit card is protected by the invention. In order to make the system more 
effective a look server can be added. The role of a look up server is described in 
35 Fig. 6. By including a look vqp server in the invention configuration, the merchant 
becomes aware whether the credit card submitted ia the purchase request is protected 
by the iavention or not. 

The look vtp server maintains receives a query from a merchant containing 
40 the first 'n' digits of a credit card number \^diere 'n' is the number of digits necessary 
to identify the credit card issuer and the type of credit card in use. These digits do not 
represent individual credit cards. The look up serv^ maintains a list of these partial 
c»:edit card numbers, which is added to \^enever a new type of credit card is 
protected using the invention. The look up server can respond to the merchant with a 
45 value indicating that the type of card is either protected by tiie invention or is not. The 
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merchant dien proceeds with knowledge of the credit card's piDtection status. This 
knowledge allows the merchant to refuse to process transactions from cards protected 
by Hie inv^idon without the presentation of either 

L A Code Generation Key 
5 E. An Approval Code 

EL Bolh 

if the shopper does not provide the required information then the merchant 
can halt processing of the transaction at that point 
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CLAIMS 

1 . A meliiod and systesn for preventing credit card fimid comprising the steps of: 

5 the credit cardholdcsr provides tiie merchant with the infonnation necessary for 

credit card authorizHtion; 

the credit card issuer receives the credit card specific information obtained by 
the merchant; 

the credit card issuer processes the credit card for authorization ; 
10 if the a:edit card is authorized then the credit card issuer generates an approval 

code and this approval code is sent to the unique identification device (UID) 
of the cardholder using a conunimication network; 

the raredit card issuer communicates the authorization decisicm to the 
merchant; 

IS the merchant prompts the cardholder to supply an approval code; 

the cardholder sup plies the approval code they have received via their unique 
identification devicje OUID); 

the merchant sends the approval code presented by the shopper to the credit 
card issuer; 

20 the credit card iss^uer compares the approval code it has generated wilfa the 

approval code sent by the merchant; 

the credit card isstter approves the credit card transaction only if the approval 
codes match. 

25 2. A method and system for prevrating credit card fraud comprising the steps o£ 

the credit cardholder provides the merchant with the information necessary for 
credit card aufhorLsation; 

the credit card issuer receives the credit card specific information obtained by 
30 the merchant; 

the credit card issuer processes the credit card for audiorizadon; 

if the credit card is authorized then the credit card issuer generates an approval 

code, which is made available to the cardholder in a mutually agreed protected 

environment; 

3S the credit card issuer communicates the authorization decision to the 

merchant; 

die merchant pioirpts the cardholder to si^ly an eppravBl code; 

the cardholder retrieves the approval code fiom the mutually agreed protected 

environment; 

40 the cardholder sucpplies the merchant with the q>proval code Ifaey have 

retrieved; 

the merchant sends the approval code presented by the shopper to the credit 
card issuer; 

the credit card issuer compares the approval code it has generated with the 
45 approval code sent by die merchant 



20 



wo 02/059849 PCT/TRO 1/00003 



the ciedit card issuer approves the credit card transaction only if the approval 
codes match. 

3. A method and system for preventing credit card fraud comprising tiie steps of: 

5 

the credit cardholder provides the merchant with the information necessary for 
credit card authorization; 

the cardholder uses their unique identification device (UID) to generate an 
approval code hased on the code generation key associated with their credit 
10 card; where code generation key is :m alphanumeric code used to verify the 

identity of the cardholder and it is accessible only by the credit card issuer and 
the cardholder; 

the cardholder provides the merchant widi this approval code; 

the merchant sends the credit card sp-^cific information with ^e approval code 
IS to the credit card issuer; 

the credit card issuer receives the information sent by the merchant; 

the credit card issuer processes the credit card for authorization; 

if the credit card is authorized then the credit card issuer generates an approval 

code based on the code genemtion key associated with the o-edit card; 
20 the credit card issuer compares the approval code it has generated with the 

approval code sent by the merchant; the credit card issuer approves the credit 

card transaction only if the approval codes match. 

4. A method and system for preventing credit card fraud comprising the steps of: 

25 

the credit cardholder provides the merchant with the information necessary for 
credit card authorization; 

the credit cardholder provides the merchant with the code generation key 
associated with their credit card; where code generation key is an 
30 alphanumeric code used to verify the identity of the cardholder and it is 

accessible only by the credit card issuer and the cardholder; 
the credit card issuer receives the cnsdit card specific information obtained by 
the merchant; 

the credit card issuer processes the ci'edit card for authorization ; 
35 if the credit cardholder has provided a code generation key and the transaction 

has been authorized by the credit c^ard issuer then flie following additional 
steps take place: 

the credit card issuer generates an approval code using the code generation 
key associated with the credit card and this approval code is sent to the unique 
40 identification device (UID) of the cardholder using a communication network; 

the credit card issu^ communicates the authorization decision to the 
merchant; 

the merc^iant generates an approval code based on the code generation key 
provided by tiie credit cardholder; 
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the merchant prompts the credit cardholder to siqiply the approval code ihat 
has been received fix)m the credit card Issuct via the cardholder's unique 
identification device (UID); 

the merchant conq>are5 the approval code it has generated with the approval 
5 code provided by ^e cardholder; 

the result of the conoparison allows the merchant to make a decision regarding 
the legitimacy of the transaction. 

5. A cozDmunication component referred to as Unique Identification Device 
10 (Un^) ^® method of claims 1»4 is a device that is capable of receiving 

messages. 

6. A communication component referred to as Unique Id^tification Device 
(UID) in the method of claims 1,4 is a device that is capable of receiving and 

IS sending messages. 

7. A communication component referred to as Unique Identification Device 
(UID) in the method of claims S, 6 is a mobile phone. 

20 8. A communication component referred to as Unique Identification Device 

(UED) in the method of claims 5, 6 is an e-mail account 

9. A commuidcation component referred to as Unique Identification Device 
(UID) in the method of claims S» 6 is a wireline phone (or Phone Number??). 

25 

10. A communication component referred to as Unique Identification Device 
(UID) in the method of claims 5, 6 is a wireless phone. 

1 1 . A communication component referred to as Unique Identification Device 
30 (tUD) in the method of claims 5,6 is a pag^ device. 

12. A communication component referred to as Unique Identification Device 
(UID) in the method of claims 5,6 is a personal computer. 

35 13. A communication component referred to as Unique Identification Device 

(UID) in the method of claims 5,6 is a personal digital! assistant (pda) device. 

14. A communication component referred to as UID in the method of claim 3 is a 
device that is capable of generating approval code. 

40 

15. A communication conq>onent referred to as USD in the melhod of claim 14 is 
a personal computer. 

16. A communication component referred to as UID in the metiiod of claim 14 is 
45 a personal digital assistajot (pda). 
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17. A communication compcment le&ired to as UID in Ihe method of claim 14 is 
a mobile phone. 

5 18. A communication componmt le&rred to as UID in the method of claim 14 is 

a pager device. 

19. A communication component referred to as UID in the method of claim 14 is 
an electronic organizer device. 

10 

20. A method as in claims 3 and 4 of generating an alphanumeric code using a 
Code Generation Key and an adjusted date/time stamp where the adjustment 
of date/time stamps is based on a time-zone agreed on as a point of nference 
by all systCTtis involved in the processes of generating or comparing approval 

15 codes. 

21. A method as in claims 1, 2, 3, 4 of enabling the merchant, in a credit card 
transaction, to ascertain whether an individual credit card is protected by the 
method and system throu^ reference to a 'look up' server containing records 

20 of all types of credit cards protected by the method and system. 

22. The method of claims I, 4 v^erein the cardholder is informed, via thc^ir UID, 
of attempted fraudulent use of their credit card account by a tiiird part} . 

25 23. The method of claim 22 v^erein the cardholder notifies their credit card 

issuer of attempted fraudulent use by replying to a message received via their 
UID. 

24. The method of claim 23 where the reply mechanism is a return e-mail address 
30 on an email message containing the approval code generated by tbe credit 

card issuer. 

25. The method of claim 23 where the reply mechanism is an originathig GSM 
number on a GSM SMS message containing the approval code generated by 

35 the credit card issuer. 

26. The method of claim 23 i?^ere the reply mechanism is a telephone number 
that connects to an automatic call directing service. 

40 27. The method of claim 24 v^diere the reply mechanism is a website. 
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Figure l.c 
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Figure 2.b 
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Figure 3. 
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Figure 3.c 
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